Reception apparatus, reception method, transmission apparatus, and transmission method

ABSTRACT

The present technology relates to a reception apparatus, a reception method, a transmission apparatus, and a transmission method and more particularly to a reception apparatus, a reception method, a transmission apparatus, and a transmission method, by which bearers transmitted by a plurality of transmission systems are selected appropriately. The reception apparatus acquires control information including information for acquiring data transmitted through a in a first transmission system at a first layer in a protocol stack of an IP (Internet Protocol) transmission system and for identifying a bearer that transmits the data in a second transmission system at a second layer lower than the first layer; and controls an operation of each unit that acquires the data transmitted on the bearer on the basis of the control information. The present technology is applicable to a television receiver corresponding to ATSC3.0, for example.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. Ser. No. 15/302,371, filedOct. 6, 2016 which is a National Stage of PCT/JP2016/054070, filed Feb.12, 2016 and claims the benefit of priority to Japanese Application No.2015-038060, filed Feb. 27, 2015, the entire contents of each of whichare incorporated herein by reference.

TECHNICAL FIELD

The present technology relates to a reception apparatus, a receptionmethod, a transmission apparatus, and a transmission method and moreparticularly to a reception apparatus, a reception method, atransmission apparatus, and a transmission method, by which bearerstransmitted by a plurality of transmission systems are selectedappropriately.

BACKGROUND ART

In recent years, main streaming services on the Internet are becomingso-called OTT-V (Over The Top Video). A widespreading basic technologyof the OTT-V is MPEG-DASH (Dynamic Adaptive Streaming over HTTP) (seeNon-Patent Document 1, for example).

The MPEG-DASH is based on a streaming protocol based on HTTP (HypertextTransfer Protocol). As to contents suitable for simultaneousmulti-destination delivery, it is contemplated that the bearers of amulticast (MC) and a broadcast (BC) are used in combination to decreasenetwork resource loads.

-   Non-Patent Document 1: ISO/IEC 23009-1:2012

SUMMARY Problem to be Solved

By the way, when data of the contents suitable for broadcasting istransmitted by a plurality of transmission systems, it is necessary toprovide a technology for appropriately selecting the bearers transmittedby different transmission systems.

The present technology has been made in view of the above-mentionedcircumstances to be capable of appropriately selecting the bearerstransmitted by a plurality of transmission systems.

Means for Solving the Problem

A reception apparatus according to a first aspect of the presenttechnology is a reception apparatus including: an acquisition unit thatacquires control information including information for acquiring datatransmitted through a session in a first transmission system at a firstlayer in a protocol stack of an IP (Internet Protocol) transmissionsystem and for identifying a bearer that transmits the data in a secondtransmission system at a second layer lower than the first layer; and acontrol unit that controls an operation of each unit that acquires thedata transmitted on the bearer on the basis of the control information.

The reception apparatus according to the first aspect of the presenttechnology may be an independent apparatus or may be an internal blockconfiguring a single apparatus. A reception method according to a firstaspect of the present technology is a reception method corresponding tothe reception apparatus according to the first aspect of the presenttechnology.

In the reception apparatus and the reception method according to thefirst aspect of the present technology, control information includinginformation for acquiring data transmitted through a session in a firsttransmission system at a first layer in a protocol stack of an IP(Internet Protocol) transmission system and for identifying a bearerthat transmits the data in a second transmission system at a secondlayer lower than the first layer is acquired; and an operation of eachunit that acquires the data transmitted on the bearer is controlled onthe basis of the control information.

A reception apparatus according to a second aspect of the presenttechnology is a transmission apparatus including: a generation unit thatgenerates control information including information for acquiring datatransmitted through a session in a first transmission system at a firstlayer in a protocol stack of an IP transmission system and foridentifying a bearer that transmits the data in a second transmissionsystem at a second layer lower than the first layer; and a transmissionunit that transmits the data by the bearer identified by informationincluded in the control information together with the controlinformation.

The reception apparatus according to the second aspect of the presenttechnology may be an independent apparatus or may be an internal blockconfiguring a single apparatus. A reception method according to a secondaspect of the present technology is a transmission method correspondingto the reception apparatus according to the second aspect of the presenttechnology.

In the reception apparatus and the reception method according to thesecond aspect of the present technology, control information includinginformation for acquiring data transmitted through a session in a firsttransmission system at a first layer in a protocol stack of an IPtransmission system and for identifying a bearer that transmits the datain a second transmission system at a second layer lower than the firstlayer is generated; and the data is transmitted by the bearer identifiedby information included in the control information together with thecontrol information.

Effects

In accordance with the first aspect and the second aspect of the presenttechnology, it is possible to appropriately select transmitted by aplurality of transmission systems.

It should be noted that the effect described here is not necessarilylimitative and may be any effect described in the present disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 A diagram showing a protocol stack of 3GPP-(e)MBMS.

FIG. 2 A diagram showing a protocol stack of ATSC3.0.

FIG. 3 A diagram showing a structure of ROUTE/FLUTE.

FIG. 4 A diagram showing a detailed structure of FLUTE.

FIG. 5 A diagram showing a detailed structure of ROUTE.

FIG. 6 A diagram showing an example of fragmentation in ROUTE.

FIG. 7 A diagram showing a disintegration of a ROUTE header.

FIG. 8 A diagram showing an example of a fragment transfer sequence byROUTE.

FIG. 9 A diagram showing a protocol stack of 3GPP-(e)MBMS envisaged inthe future.

FIG. 10 A diagram showing a configuration example of a transmissionsystem.

FIG. 11 A diagram showing a configuration of a ROUTE session.

FIG. 12 A diagram showing a configuration of LSID.

FIG. 13 A diagram showing a detailed content of an LSID element.

FIG. 14 A drawing explaining a flow of data acquisition using LSID.

FIG. 15 A drawing explaining a flow of data acquisition using anextended LSID.

FIG. 16 A diagram showing other structure of an extended LSID.

FIG. 17 A diagram explaining a flow of data acquisition using anextended LSID into which a transport bearer ID is described.

FIG. 18 A diagram showing a first structure of an extended LSID.

FIG. 19 A diagram showing a specific description example of the firststructure of an extended LSID.

FIG. 20 A diagram showing a second structure of an extended LSID.

FIG. 21 A diagram showing a specific description example of the secondstructure of an extended LSID.

FIG. 22 A diagram showing a specific application example of a receptionside system that processes broadcasting stream transmitted from areception side system.

FIG. 23 A diagram showing a configuration example of a transmission sidesystem.

FIG. 24 A diagram showing a configuration example of a reception sidesystem.

FIG. 25 A flowchart for explaining a flow of processing of atransmission side system.

FIG. 26 A flowchart for explaining a flow of processing of a receptionside system.

FIG. 27 A diagram showing a configuration example of a computer.

DESCRIPTION OF PREFERRED EMBODIMENTS

Hereinafter, embodiments of the present technology will be describedwith reference to the drawings. Note that descriptions will be made inthe following order.

1. Outline of Digital Broadcasting in IP Transmission System

2. System Configuration

3. Extended LSID to which the present technology is applied

(1) Outline of LSID

(2) Extended LSID

(3) Transport Bearer Identification by Extended LSID

4. Specific Application Example of System

5. Apparatuses Configuration in System

6. Flow of Processing Executed by Apparatuses in System

7. Alternative Embodiment

8. Configuration of Computer

1. Outline of Digital Broadcasting in IP Transmission System

In a digital broadcasting standard in each country, an MPEG2-TS (MovingPicture Experts Group phase 2-Transport Stream) system is employed as atransmission system. It is assumed that more enhanced services areprovided in the future by introducing the IP transmission system whereIP (Internet Protocol) packets used in the field of communication areused for digital broadcasting. In particular, in ATSC (AdvancedTelevision Systems Committee) 3.0, a next generation broadcastingstandard in the United States that has been currently formulated,digital broadcasting using the IP transmission system is expected to beemployed.

Hereinafter, an outline of the digital broadcasting using the IPtransmission system is described. Here, an outline of 3GPP-(e)MBMS(Multimedia Broadcast Multicast Service) formulated by 3GPP (ThirdGeneration Partnership Project) that is a standardization project of amobile communication system is firstly described.

(Protocol Stack of 3GPP-(e)MBMS)

FIG. 1 is a diagram showing a protocol stack of 3GPP-(e)MBMS.

In FIG. 1, a lowest hierarchy is a physical layer. In 3GPP-(e)MBMS, whena transmission system on the right-hand side of the figure is used, thephysical layer uses either of one directional MBMS or both directionalptp Bearer(s).

An upper hierarchy adjacent to the physical layer is an IP layer. Inaddition, an upper hierarchy adjacent to the IP layer is a UDP/TCPlayer. That is to say, when the MBMS is used as the physical layer, anIF multicast is used in the IP layer, and a UDP (User Datagram Protocol)is used in the UDP/TCP layer. On the other hand, when the ptp Bearer(s)is used as the physical layer, an IP unicast is used in the IP layer,and a TCP (Transmission Control Protocol) is used in the UDP/TCP layer.

The upper hierarchies adjacent to the UDP/TCP layer are FEC, HTTP(S),FLUTE. The FLUTE (File Delivery over Unidirectional Transport) is aprotocol for file transfer in the multicast. Note that FEC (ForwardError Correction) is applied to the FLUTE. A detail of the FLUTE will bedescribed below by referring to FIG. 3, and the like.

The upper hierarchies adjacent to the FLUTE are 3GP-DASH, Download 3GPPfile format etc., ptm File Repair, Service Announcement & Metadata. Theupper hierarchy adjacent to the ptm File Repair is Associated DeliveryProcedures.

The upper hierarchy adjacent to 3GP-DASH (Dynamic Adaptive Streamingover HTTP) is stream data such as audio and video. That is to say, thestream data such as audio and video configuring contents can betransmitted through a FLUTE session in units of media segments complyingwith an ISO BMFF (Base Media File Format) standard.

In addition, USD (User Service Description) and MPD (Media PresentationDescription) can be provided as the control information of the streamdata transmitted through the FLUTE session on Service Announcement &Metadata, for example. Therefore, the control information such as theUSD and the MPD can also be transmitted through the FLUTE session.

In this manner, 3GPP-(e)MBMS specifies protocols for file downloadingthrough the FLUTE session of the files based on a 3GPP file format (ISOBMFF file, MP4 file). By the same protocol, a fragmented MP4 filesequence of the MPEG-DASH and the MPD complying with a standard of theMPEG-DASH can be transmitted. The MPD is referred by the USD. Thefragmented MP4 means a fragmented MP4 file.

The upper hierarchy of HTTP(S) that is an upper hierarchy adjacent tothe UDP/TCP layer is stream data of 3GP-DASH. That is to way, streamdata of the 3GP-DASH can also be transmitted using the HTTP(S). Theupper hierarchies of the FEC that is an upper hierarchy adjacent to theUDP/TCP layer is RTP/RTCP and MIKEY. The upper hierarchy of the RTP/RTCPis RTP PayloadFormats, and the further upper hierarchy is stream data.In other words, the stream data can be transmitted through the RTP (Realtime Transport Protocol) session. The upper hierarchy of MIKEY is KeyDistribution (MTK), and the further upper hierarchy is MBMS Security.

On the other hand, when a transmission system on the left-hand side ofthe figure is used, the physical layer uses only both directional ptpBearer(s). An upper hierarchy adjacent to the physical layer is an IPlayer. In addition, an upper hierarchy adjacent to the IP layer is a TCPlayer, and an upper hierarchy adjacent to the TCP layer is a HTTP(S)layer. Thus, by these hierarchies, the protocol stack that is worked ona network such as the Internet is implemented.

The upper hierarchies adjacent to the HTTP(S) layer are ServiceAnnouncement & Metadata, ptm File Repair, Reception Reporting, andRegistration. The USD and the MPD can be provided as the controlinformation of the stream data transmitted through the FLUTE sessionusing the transmission system shown on the right-hand side of the figureon Service Announcement & Metadata. Therefore, the control informationsuch as the USD and the MPD can be provided through a server on theInternet, for example.

The upper hierarchies adjacent to ptm File Repair and ReceptionReporting are Associated Delivery Procedures. The upper hierarchyadjacent to Registration is MBMS Security. The upper hierarchy adjacentto the UDP layer that is the upper hierarchy adjacent to the IP layer isMIKEY. The upper hierarchy of the MIKEY is Key Distribution (MTK), andthe further upper hierarchy is MBMS Security. For example, using theFLUTE session in the case of using the transmission system shown on theright-hand side of the figure and the TCP/IP protocol using thetransmission system shown on the left-hand side of the figure,applications can be transmitted.

(Protocol Stack of ATSC3.0)

FIG. 2 is a diagram showing a protocol stack of ATSC3.0.

In FIG. 2, a lowest hierarchy is a physical layer. In a digitalbroadcasting in an IP transmission system such as ATSC3.0, transmissionis not limited to utilize broadcasting, and may utilize communicationfor a part of data. When broadcasting is utilized, the frequency band ofbroadcast waves assigned for a service (channel) corresponds to thephysical layer (Broadcast PHY).

The upper hierarchy of the physical layer (Broadcast PHY) is an IP layer(IP multicast). The IP layer corresponds to an IP (Internet Protocol) inthe protocol stack of TCP/IP. IP packets are specified by an IP address.The upper hierarchy adjacent to the IP layer is a UDP layer, the furtherupper hierarchy is ROUTE (Real-time Object Delivery over UnidirectionalTransport). The ROUTE is a protocol for file transfer in the multicast,and extends FLUTE. A detail of the ROUTE will be described below byreferring to FIG. 3, and the like.

Parts of the hierarchy within the upper hierarchies adjacent to ROUTEare ESG (Electronic Service Guide) service and NRT contents. Files ofthe ESG service and the NRT contents are transmitted through a ROUTEsession. The ESG service is an electronic service guide (programinformation). The NRT contents are contents transmitted in NRT (Non RealTime) broadcasting, stored in a storage of the reception unit, and thenregenerated. Note that the NRT contents are illustrative contents andother content files may be transmitted through the ROUTE session.

Other hierarchy other than the above-described hierarchies within theupper hierarchies adjacent to the ROUTE is DASH (ISO BMFF). The upperhierarchies adjacent to DASH (ISO BMFF) are stream data of componentssuch as video, audio, a closed caption (CC) and the like. That is tosay, stream data of components such as video, audio, a closed captionand the like can be transmitted through the ROUTE session in units ofmedia segments complying with a standard of ISO BMFF.

The hierarchy across the upper hierarchy adjacent to the physical layer(Broadcast PHY) and the hierarchy adjacent to the ROUTE is signalinginformation (Singaling). For example, signaling information includes LLS(Link Layer Signaling) signaling information and SLS (Service LevelSingaling) signaling information.

The LLS signaling information is low-layer signaling information notdepending on services. For example, the LLS signaling informationincludes metadata such as FIT (Fast Information Table), EAD (EmergencyAlerting Description), RRD (Region Rating Description) and the like. TheFIT includes stream or service configuration information in abroadcasting network such as information necessary for serviceselection. The EAD includes information about an emergency alert. TheRRD includes information about rating.

The SLS signaling information is signaling information per service. Forexample, the SLS signaling information includes metadata such as LSID(LCT Session Instance Description) as well as the above-described USDand MPD. The LSID is control information (control meta file) of theROUTE protocol. A detail of the ROUTE will be described below byreferring to FIG. 3, and the like.

On the other hand, when the communication is utilized, the upperhierarchy of the physical layer (Broadband PHY) is an IP layer (IPunicast). The upper hierarchy adjacent to the IP layer is a TCP layer,and the upper hierarchy adjacent to the TCP layer is an HTTP(S) layer.Thus, by these hierarchies, the protocol stack that is worked on anetwork such as the Internet is implemented.

In this manner, the reception unit communicates with the server on theInternet, for example, using the TCP/IP protocol, and can receive theESG service, the signaling information, the NRT contents and the like.In addition, the reception unit can receive stream data such as audioand video adaptively streaming delivered from the server on theInternet. Note that the streaming delivery is comply with a standard ofthe MPEG-DASH.

For example, applications can be transmitted using a broadcasting ROUTEsession and a communication TCP/IP protocol. The applications can bedescribed with a markup language such as HTML5 (HyperText MarkupLanguage 5) and the like.

As described above, the protocol stack of ATSC3.0 employs the protocolstack, a part of which corresponds to 3GPP-MBMS. In this manner, streamdata such as audio and video configuring the contents can be transmittedin units of media segments complying with a standard of ISO BMFF. Whenthe signaling information such as the SLS signaling information istransmitted by any of broadcasting or communication, the protocol can becommon in the hierarchy excluding the physical layer (and the data linklayer) that is the lower hierarchy than the IP layer, i.e., the upperhierarchy than the IP layer, thereby reducing implementation burden orprocessing burden in the reception unit and the like.

(Structure of ROUTE/FLUTE)

FIG. 3 is a diagram showing a structure of FLUTE in the protocol stackof 3GPP-(e)MBMS in FIG. 1 and ROUTE in the protocol stack of ATSC3.0 inFIG. 2.

The FLUTE is configured of a multicast protocol of a scalable fileobject called as ALC (Asynchronous Layered Coding), specifically acombination of LCT (Layered Coding Transport) and FEC (Forward ErrorCorrection) components that are building blocks. FIG. 4 shows a detailedstructure of the FLUTE.

Here, the ALC is a protocol suitable for multicast transferring anoptional binary file in one direction. Specifically, the ALC has beendeveloped as a high reliable asynchronous one-to-many broadcastingprotocol. The ALC utilizes LCT and FEC, performs FEC on a targeted fileto be stored in an LCT packet. When the file is transferred on an IPmulticast, the file is stored in a UDP packet and an IP packet.

A transport session in the FLUTE is identified by a unique TSI(Transport Session Identifier) within a scope of a source IP address.The FLUTE can change a FEC system per transport session, or per file. Inaddition, transfer control information in an XML (Extensible MarkupLanguage) format referred to as FDT (File Delivery Table) transferredper transport session is introduced into the FLUTE.

Basic attributes and transfer control parameters of the targeted fileare described in an FDT file transferred within the same transportsession as of an FEC encoding symbol strode in the LCT packet. The FDTcan define mapping of LCT packet columns in which FEC encoding symbolcolumns corresponding to an identifier of the targeted file are stored,and store a MIME type and a size of a content in each file, a transferencoding system, a message digest, and parameters necessary for FECdecoding. Note that it is possible to apply FEC to FDT itself. Own FECparameters will be transmitted in LCT layers, separately.

The ROUTE is extended of the FLUTE. A difference may be mainly an objectbundle and a media aware fragmentation. FIG. 5 shows a detailedstructure of the ROUTE.

The object bundle in the ROUTE is characterized to support in a protocollevel a method of generating an FEC repair stream, and a notification ofa relationship between a source stream and a repair stream.Specifically, a video or audio stream is bundled from source blockshaving different sizes to form one super object, thereby generating theFEC repair stream.

In general, as the audio stream has a data volume (data object) is smallper unit time data, the audio stream has a small source object size ascompared with the video stream. When repair symbol is generated perstream in the same FEC system to the streams having different sourceobject sizes, error sensitivity is different depending on a large orsmall size of the source object.

The ROUTE can take out the source blocks from the different sourcestreams having a plurality of rates, and configure the super object. Therepair stream can be configured by the FEC repair symbol generatedtherefrom. That is to say, the repair stream is generated acrossdifferent types of the source streams. Here, the source streamsincluding source symbols and the repair streams including repair symbolscan be transferred through other LCT sessions within the ROUTE session.

Information (control information) about how the super object isconfigured from the source blocks taken out from a plurality of thesource streams to generate FEC streams is described to LSID (LCT SessionInstance Description). At a reception unit side, the super object isrestored from LCT packet columns transmitted through the ROUTE sessionbased on the information described in the LSID, and the targeted filecan be extracted.

In general, a broadcasting stream is a model that multiplexes andtransmits all streams configuring services at a transmission unit side,and chooses the stream necessary for own at the reception unit side.Accordingly, in a use case to which the processing model described belowis applicable, an FEC configuration method is effective. The processingmodel is that the super object including all streams configuringservices is configured, the super object is restored at the receptionunit side, and the necessary stream is chosen.

As shown in FIG. 6, a media aware fragmentation is possible in theROUTE. FIG. 6 shows an example of the fragmentation when the DASHsegment is an Indexed Self-Initialization segment.

In FIG. 6, a metadata part of the segment is divided at pckt0 that is afirst delivery object, and a first sample 1 is stored in pckt1. In orderto show boundaries to be separated, an URL (Uniform Resource Locator) ofeach delivery object is described in the prat corresponding to the FDTcorresponding to the LSID. A format of the URL may be a format in an URLof a segment file and a byte range, or a format in an URL of a segmentfile and a subsegment number. When the subsegment number is “0”, it is ametadata part.

As the format of the delivery object, there are prepared a “file mode”that the object itself is stored, and a “entity mode” that an object towhich an HTTP entity header is added is stored. These modes aredescribed as attributes of the LSID source streams. The URL and the byterange of the object can be stored in the HTTP entity header, and theattributes described by the FDT in the past can be included therein.

In the FLUTE, when the targeted file is separated into the sourceblocks, a predetermined algorithm is applied, and separation ismechanically performed without awaring of processing boundaries of theapplications and the like. In contrast, in the ROUTE, the source blockscan be separated at free boundaries irrespective of the applications.FIG. 7 shows an example that the source delivery object is stored in atransport packet. When the source delivery object is stored in a payloadof a lower LCT packet, a ROUTE header is added, if separation isnecessary, thereby specifying an offset within the delivery object.

FIG. 8 shows that data is transferred from a ROUTE server (ROUTE Sender)to a ROUTE client (ROUTE Reception unit) in units of source deliveryobjects. In general, the delivery objects are transferred in the order.To enhance an experienced speed when a channel is switched, the deliveryobject in which metadata such as SLS signaling information is stored canbe frequently resend.

In the above, the ROUTE that is an extension of the FLUTE has beendescribed. Also in the protocol stacks of the above-described present3GPP-(e)MBMS (FIG. 1), it is assumed that the ROUTE is specified insteadof the FLUTE, or together with the FLUTE, in the future (FIG. 9). In thefollowing description, 3GPP-(e)MBMS is described as 3GPP-MBMS.

2. System Configuration

FIG. 10 is a diagram showing a configuration example of a transmissionsystem to which the present technology is applied.

In FIG. 10, a transmission system 1 includes a transmission side system10, and a reception side system 20. In the transmission system 1, datatransmitted from the transmission side system 10 is received by thereception side system 20 via a transmission path 80 or a transmissionpath 90.

The transmission side system 10 corresponds, for example, to apredetermined standard such as ATSC3.0 and 3GPP-MBMS. The transmissionside system 10 is configured of a data server 10A, a ROUTE server 10B,an ATSC broadcasting server 100 and a 3GPPMBMS server 10D.

The data server 10A is a server that manages data of contents (forexample, simultaneous multi-destination delivery is suitable) deliveredfrom the transmission side system 10 to the reception side system 20.The data server 10A supplies the ROUTE server 10B with the data ofcontents.

The ROUTE server 10B is a server that performs processing fortransmitting the data of contents supplied from the data server 10Athrough the ROUTE session.

The ROUTE server 10B generates an extended LSID based on informationsupplied from the ATSC broadcasting server 10C and the 3GPPMBMS server10D, and supplies the ATSC broadcasting server 10C or the 3GPPMBMSserver 10D with the extended LSID. The extended LSID is provided byextending the LSID, a detail of which will be described below byreferring to FIG. 15, and the like.

In addition, the ROUTE server 10B processes the data of contentssupplied from the data server 10A, generates the data of contentstransmitted through the ROUTE session (hereinafter, also referred to asROUTE data), and supplies the ATSC broadcasting server 10C or the3GPPMBMS server 10D with the data of contents.

The ATSC broadcasting server 10C is a server that ROUTE data from theROUTE server 10B is transmitted by a transport bearer corresponding toATSC3.0.

The ATSC broadcasting server 10C transmits the extended LSID suppliedfrom the ROUTE server 10B to the reception side system 20 (ATSCbroadcasting client 20C) via the transmission path 80. In addition, theATSC broadcasting server 10C performs processing for transmitting ROUTEdata supplied from the ROUTE server 10B on the transport bearer ofATSC3.0, and transmits (simultaneous multi-destination delivers)obtained data (hereinafter, also referred to as bearer data) to thereception side system 20 (ATSC broadcasting client 20C) via thetransmission path 80.

The 3GPPMBMS server 10D is a server for transmitting the ROUTE data fromthe ROUTE server 10B by the transport bearer corresponding to 3GPP-MBMS.

The 3GPPMBMS server 10D transmits the extended LSID supplied from theROUTE server 10B to the reception side system 20 (3GPPMBMS client 20D)via the transmission path 90. In addition, the 3GPPMBMS server 10Dperforms processing for transmitting the ROUTE data supplied from theROUTE server 10B on the transport bearer of 3GPPMBMS, and transmits(simultaneous multi-destination delivers) obtained bearer data to thereception side system 20 (3GPPMBMS client 20D) via the transmission path90.

The reception side system 20 corresponds, for example, to apredetermined standard such as ATSC3.0 and 3GPP-MBMS. The reception sidesystem 20 is configured of a data client 20A, a ROUTE client 20B, anATSC broadcasting client 20C, and a 3GPPMBMS client 20D.

The 3GPPMBMS client 20D is a client for receiving the transport bearercorresponding to 3GPP-MBMS transmitted from the transmission side system10.

The 3GPPMBMS client 20D receives the extended LSID supplied from the3GPPMBMS server 10D via the transmission path 90, and supplies the ROUTEclient 20B with the extended LSID. In addition, the 3GPPMBMS client 20Dreceives and processes the bearer data transmitted (simultaneousmulti-destination delivered) from the transmission side system 10(3GPPMBMS server 10D) via the transmission path 90, and supplies theROUTE client 20B with the bearer data.

The ATSC broadcasting client 20C is a client for receiving the transportbearer corresponding to ATSC3.0 transmitted from the transmission sidesystem 10.

The ATSC broadcasting client 20C receives the extended LSID suppliedfrom the ATSC broadcasting server 100 via the transmission path 80, andsupplies the ROUTE client 20B with the extended LSID. In addition, theATSC broadcasting client 20C receives and processes the bearer datatransmitted (simultaneous multi-destination delivered) from thetransmission side system 10 (ATSC broadcasting server 100) via thetransmission path 80, and supplies the ROUTE client 20B with the bearerdata.

The ROUTE client 20B is a client for processing the ROUTE datatransmitted on the transport bearer of ATSC3.0 or 3GPP-MBMS.

The ROUTE client 20B acquires the ROUTE data transmitted on thetransport bearer (the bearer data) of ATSC3.0 or 3GPP-MBMS based on theATSC broadcasting client 20C or 3GPPMBMS client 20D, and supplies thedata client 20A with the ROUTE data.

The data client 20A is a client for regenerating data of contentsdelivered (simultaneous multi-destination delivered) from thetransmission side system 10 to the reception side system 20. The dataclient 20A regenerates the data of contents (for example, simultaneousmulti-destination delivery is suitable) supplied from the ROUTE client20B, and outputs video and sound.

FIG. 10 shows the ATSC broadcasting server 10C and the ATSC broadcastingclient 20C corresponding to ATSC3.0, and the 3GPPMBMS server 10D and the3GPPMBMS client 20D corresponding to 3GPPMBMS, and illustrates the casethat the transport bearers corresponding to the standards are processed.Any server and client corresponding to any standards other than ATSC3.0and 3GPP-MBMS may be provided. For example, when the ROUTE is datatransmitted by a transport bearer of DVB (Digital VideoBroadcasting)-based IP broadcasting (IP over MPEG2-TS), a DVBbroadcasting server corresponding to the DVB transport bearer is addedat the transmission side system 10, and a DVB broadcasting clientcorresponding to the DVB transport bearer is added at the reception sidesystem 20.

In addition, in the transmission system 1 in FIG. 10, only one receptionside system 20 is shown as a matter of explanation convenience.Actually, a plurality of (many) reception side systems 20 that canreceive the contents simultaneous multi-destination delivered from thetransmission side system 10 are disposed. Also, it is assumed that thereception side system 20 may corresponds only to ATSC3.0, not to3GPP-MBMS, for example. In this case, the 3GPPMBMS client 20D isexcluded from the configuration, the reception side system 20 isconfigured of the data client 20A, the ROUTE client 20B and the ATSCbroadcasting client 20C.

Furthermore, in FIG. 10, it is described that the transmission sidesystem 10 is configured of a plurality of servers including the dataserver 10A to the 3GPPMBMS server 10D. It may be possible to considerthe transmission side system 10 as a transmission apparatus(transmission unit) including all functions of the servers. Similarly,it is described that the reception side system 20 is configured of aplurality of clients including the data client 20A to the 3GPPMBMSclient 20D. It may be possible to consider the reception side system 20as a reception apparatus (reception unit) including all functions of theclients.

3. Extended LSID to which the Present Technology is Applied

(1) Outline of LSID

(Configuration of ROUTE Session)

FIG. 11 is a diagram showing a configuration of a ROUTE session.

As shown in FIG. 11, the ROUTE session may be configured of one or aplurality of LCT sessions. The ROUTE session is identified by a sourceIP address (sIPAdrs) and a destination IP address (dIPAdrs) that areparameters stored in an IP header of the IP packet, and a port number(Port) that is a parameter stored in a UDP header of the UDP packet. TheLCT session is identified by a TSI (Transport Session Identifier) of theLCT packet (ALC/LCT packet).

Any signaling information (for example, SLS signaling information)transmitted from the transmission side system 10 (ROUTE server 10B) tothe reception side system 20 (ROUTE client 20B) notifies the source IPaddress, the destination IP address and the port number for identifyingthe ROUTE session, thereby acquiring the IP/UDP packets transmittedthrough the ROUTE session.

In the ROUTE session, by filtering the LCT packet where the TSI=0, theLSID that is the control information (control metafile) of the ROUTEprotocol can be obtained. Note that the LCT packet where the TSI=0 isfiltered to acquire the LSID only when the LSID is transmitted throughthe ROUTE session.

(Configuration of LSID)

FIG. 12 is a diagram showing a configuration of the LSID.

As shown in FIG. 12, a source stream (SourceFlow) and a repair stream(RepairFlow) are described into the LSID per one or a plurality oftransport sessions (TransportSession). FIG. 13 shows a detaileddescription of an LSID element. The TSI that is an identifier of the LCTsession is described into the LSID other than the source stream and therepair stream as attributes per LCT session (transport session)configuring the ROUTE session.

(Flow of Data Acquisition Using LSID)

FIG. 14 is a drawing explaining a flow of data acquisition using theLSID in the reception side system 20.

In FIG. 14, the reception side system 20 acquires information about theROUTE session from any signaling information notified from thetransmission side system 10 (S11). Information about attributes of aROUTE session 1 and a ROUTE session 2 in the broadcasting streamtransferred (transmitted) from the transmission side system 10 isdescribed into the signaling information.

Here, as the attribute of the ROUTE session 1, the source IP address“sIPAdrs1”, the destination IP address “dIPAdrs1”, and the port number“Port1” are designated. As the attributes of the ROUTE session 2, thesource IP address “sIPAdrs1”, the destination IP address “dIPAdrs2”, andthe port number “Port1” are designated.

The reception side system 20 acquires IP/UDP packets transferred throughthe ROUTE session 1 identified by the source IP address “sIPAdrs1”, thedestination IP address “dIPAdrs1”, and the port number “Port1” accordingto the information about the attributes of the ROUTE session 1 in thesignaling information (S12). Also, the reception side system 20 filtersIP/UDP/LCT packets at the TSI=in the ROUTE session 1, thereby acquiringLSID1 that is the control information of the ROUTE session 1 (S13).

The LSID1 includes the information about the attributes of the LCTsession 1 and the LCT session 2 as the attributes of the ROUTE session1.

Here, as the attributes of the LCT session 1, the TSI “tsi1” isdesignated. The reception side system 20 acquires data (IP/UDP/LCTpackets) transferred through the LCT session 1 of the ROUTE session 1identified by the source IP address “sIPAdrs1”, the destination IPaddress “dIPAdrs1”, the port number “Port1”, and the TSI “tsi1”according to the information about the attributes of the LCT session 1in the LSID1 (S14).

As the attributes of the LCT session 2, the TSI “tsi2” is designated.The reception side system 20 acquires data (IP/UDP/LCT packets)transferred through the LCT session 2 of the ROUTE session 1 identifiedby the source IP address “sIPAdrs1”, the destination IP address“dTPAdrs1”, the port number “Port1”, and the TSI “tsi2” according to theinformation about the attributes of the LCT session 2 in the LSID1(S15).

On the other hand, in the signaling information, as the attributes ofthe ROUTE session 2, the source IP address “sIPAdrs1”, the destinationIP address “dIPAdrs2”, and the port number “Port1” are designated. Thereception side system 20 processes the ROUTE session 2 similar to theabove-described ROUTE session 1.

Specifically, the reception side system 20 acquires IP/UDP packetstransferred through the ROUTE session 2 identified by the source IPaddress “sIPAdrs1”, the destination IP address “dIPAdrs2”, and the portnumber “Port1” according to the information about the attributes of theROUTE session 2 in the signaling information (S16). Also, the receptionside system 20 filters IP/UDP/LCT packets at the TSI=in the ROUTEsession 2, thereby acquiring LSID2 that is the control information ofthe ROUTE session 2 (S17).

The LSID2 includes the information about the attributes of LCT session 1as the attributes of the ROUTE session 2.

Here, as the attributes of the LCT session 1, the TSI “tsi1” isdesignated. The reception side system 20 acquires data (IP/UDP/LCTpackets) transferred through the LCT session 1 of the ROUTE session 2identified by the source IP address “sIPAdrs1”, the destination IPaddress “dIPAdrs2”, the port number “Port1”, and the TSI “tsi1”according to the information about the attributes of the LCT session 1in the LSID2 (S18).

As described above, the reception side system 20 acquires the LSIDtransmitted through the ROUTE session after any signaling information isacquired, uses the TSI described in the LSID, and can acquire datatransmitted through the LCT session of the ROUTE session.

(2) Extended LSID

In the processing using the above-described LSID, in order to acquirethe data transmitted through the LCT session of the ROUTE session, it isnecessary to acquire any signaling information, and to acquire the LSIDtransmitted through the ROUTE session, and it is therefore a requestthat the processing is simplified.

For the request, the LSID is extended to include the source IP address,the destination IP address, and the port number. In other words, thesource IP address, the destination IP address, and the port number areincluded in the LSID, whereby processing to acquire data transmittedthrough the LCT session of the ROUTE session is simplified.

Note that the source IP address is an option whether or not the sourceIP address is included in the extending LSID. In the presentapplication, the extending LSID is referred to as the extended LSID inorder to differentiate from the LSID already specified.

(Flow of Data Acquisition Using Extended LSID)

FIG. 15 is a drawing explaining a flow of data acquisition using theextended LSID.

In FIG. 15, the reception side system 20 acquires the extended LSIDnotified from the transmission side system 10 as SLS signalinginformation (S21), for example. Information about attributes of theROUTE session 1 and the ROUTE session 2 in the broadcasting streamtransferred (transmitted) from the transmission side system 10 isdescribed in the extended LSID.

Here, as the attribute of the ROUTE session 1, the source IP address“sIPAdrs1”, the destination IP address “dIPAdrs1”, and the port number“Port1” are designated. The attributes of the ROUTE session 1 includethe information about the attributes of the LCT session 1 and the LCTsession 2.

Specifically, in the attribute of the ROUTE session 1, TSI “tsi1” isdesignated in the attribute of the LCT session 1, and TSI “tsi2” isdesignated in the attribute of the LCT session 2.

Thus, the reception side system 20 can acquire data (IP/UDP/LCT packets)transferred through the LCT session 1 of the ROUTE session 1 identifiedby the source IP address “sIPAdrs1”, the destination IP address“dIPAdrs1”, the port number “Port1”, and TSI “tsi1” according to theinformation about the attribute of the ROUTE session 1 in the extendedLSID (the attribute of the LCT session 1) (S22).

Similarly, the reception side system 20 can acquire data (IP/UDP/LCTpackets) transferred through the LCT session 2 of the ROUTE session 1identified by the source IP address “sIPAdrs1”, the destination IPaddress “dIPAdrs1”, the port number “Port1”, and TSI “tsi2” according tothe information about the attribute of the ROUTE session 1 in theextended LSID (the attribute of the LCT session 2).

On the other hand, in the extended LSID, as the attribute of the ROUTEsession 2, the source IP address “sIPAdrs1”, the destination IP address“dIPAdrs2”, and the port number “Port1” are designated. In the attributeof the ROUTE session 2, as the attribute of the LCT session 1, TSI“tsi1” is designated. The reception side system 20 processes the ROUTEsession 2 similar to the ROUTE session 1 as described above.

That is to say, the reception side system 20 can acquire data(IP/UDP/LCT packets) transferred through the LCT session 1 of the ROUTEsession 2 identified by the source IP address “sIPAdrs1”, thedestination IP address “dIPAdrs1”, the port number “Port1”, and TSI“tsi1” according to the information about the attribute of the ROUTEsession 2 in the extended LSID (the attribute of the LCT session 1)(S23).

Although it is described that the attributes of one or a plurality ofLCT sessions are defined in the attributes of the ROUTE session in theextended LSID in FIG. 15, the structure of the extended LSID in FIG. 15is an example, and other structure may be employed.

For example, as shown FIG. 16, the source IP address, the destination IPaddress, and the port number may be defined together with the TSI in theattribute of the LCT session without defining the attribute of the ROUTEsession. Even if the extended LSID is used, the reception side system 20can specify one or a plurality of LCT sessions configuring the ROUTEsession.

As described above, the extended LSID includes the source IP address,the destination IP address, and the port number, and can specify the LCTsession using only the extended LSID per ROUTE session. As compared withthe LSID, it is unnecessary to acquire the LSID transmitted through theROUTE session, thereby simplifying processing concerning the signalinginformation. As a result, the processing to acquire the data transmittedthrough the LCT session of the ROUTE session is simplified.

(3) Transport Bearer Identification by Extended LSID

By the way, when the ROUTE session is transmitted on various transportbearers such as ATSC3.0, 3GPP-MBMS and the like, information for mappingto each transport bearer will be necessary. Next, a method of mappingthe ROUTE session (one or a plurality of LCT sessions configuring theROUTE session) to various transport bearers by extending the LSID.

The transport bearer corresponds, for example, to a physical layer(Broadcast PHY) in the protocol stack of ATSC3.0 in FIG. 2, or aphysical layer (MBMS or ptp Bearer(s)) in the protocol stack of3GPP-MBMS in FIG. 9.

Here, as transport media, there are ATSC3.0 transport, 3GPP-MBMStransport, DVB-based IP broadcasting transport, for example. Thetransport media have different modulation parameters and encodingparameters, and become transport pipes having different transferqualities.

In the extended LSID, as an attribute of each LCT session, an identifierfor identifying the transport bearer (hereinafter referred to as antransport bearer ID (BearerID)) is described, whereby mapping the ROUTEsession (the LCT session) and the transport bearer. A format of thetransport bearer ID is defined per targeted transport media.

(Flow of Data Acquisition Using Extended LSID)

FIG. 17 is a diagram explaining a flow of data acquisition using theextended LSID into which the transport bearer ID is described in thereception side system 20.

In FIG. 17, the reception side system 20 acquires the extended LSIDnotified from the transmission side system 10 as the SLS signalinginformation (S31). Information about attributes of the LCT session 1 andthe LCT session 2 of the ROUTE session 1 and the LCT session 1 of theROUTE session 2 in the broadcasting stream transferred (transmitted)from the transmission side system 10 is described in the extended LSID.

Here, as the attribute of the LCT session 1 of the ROUTE session 1, theTSI “tsi1”, the source IP address “sIPAdrs1”, the destination IP address“dIPAdrs1”, and the port number “Port1” are designated. In the attributeof the LCT session 1, “atsc-bid1” and “3gpp-bid1” are designated as thetransport bearer ID (BearerID)) for identifying the transport bearer.

“atsc-bidX” (X is an integer of 1 or more) is the transport bearer IDfor identifying the transport bearer of ATSC3.0. In the case of thetransport bearer of ATSC3.0, a combination of a Broadcast Stream ID andPLPID (Physical Layer Pipe ID) is the transport bearer ID.

Here, a broadcast stream ID is assigned to a set of an area ID that isan identifier assigned per reach area of a broadcast wave and afrequency ID that is an identifier of a frequency band assigned to abroadcast wave of a certain channel. PLPID is an identifier per physicalpipe when a frequency band identified by the broadcast stream ID isdivided further into a plurality of physical layer pipes (PLPs) havingdifferent modulation parameters and encoding parameters.

“3gpp-bidX” (X is an integer of 1 or more) is the transport bearer IDfor identifying the transport bearer of 3GPP-MBMS. In the case of thetransport bearer of 3GPP-MBMS, TMGI (Temporary Mobile Group Identity) isthe transport bearer ID.

Although not shown, in the case of the DVB-based IP broadcastingtransport bearer, a DVB triplet that is a combination of an originalnetwork ID (ONID), a transport ID (TID), and a service ID (SID) is thetransport bearer ID. A packet ID (PID) of MPEG2 may be further combinedwith the transport bearer ID.

Thus, the reception side system 20 can be connected to the transportbearer of ATSC3.0 identified by the transport bearer ID “atsc-bid1”according to the information about the attribute of the LCT session 1 inthe extended LSID (S32). Similarly, the reception side system 20 can beconnected to the transport bearer of 3GPP-MBMS identified by thetransport bearer ID “3gpp-bid1” according to the information about theattribute of the LCT session 1 in the extended LSID (S33).

Then, the reception side system 20 can acquire data (IP/UDP/LCT packets)transferred through the LCT session 1 of the ROUTE session 1 identifiedby the source IP address “sIPAdrs1”, the destination IP address“dIPAdrs1”, the port number “Port1”, and TSI “tsi1” according to theinformation about the attribute of the LCT session 1 in the extendedLSID (S34). It should be noted that the LCT session 1 of the ROUTEsession 1 is transmitted on the transport bearer of ATSC3.0 or thetransport bearer of 3GPP-MBMS identified by the transport bearer ID“atsc-bid1” or “3gpp-bid1” (S32, S33).

In addition, in FIG. 17, in the extended LSID, as the attribute of theLCT session 2 of the ROUTE session 1, the TSI “tsi2”, the source IPaddress “sIPAdrs1”, and the destination IP address “dIPAdrs1”, and theport number “Port1” are designated. In the attribute of the ROUTEsession 2, as the transport bearer ID for identifying the transportbearer, “atsc-bid2” is designated.

The reception side system 20 can be connected to the transport bearer ofATSC3.0 identified by the transport bearer ID “atsc-bid2” according tothe information about the attribute of the LCT session 2 in the extendedLSID (S35).

Then, the reception side system 20 can acquire data (IP/UDP/LCT packets)transferred through the LCT session 2 of the ROUTE session 1 identifiedby the source IP address “sIPAdrs1”, the destination IP address“dIPAdrs1”, the port number “Port1”, and TSI “tsi2” according to theinformation about the attribute of the LCT session 2 in the extendedLSID (S36). It should be noted that the LCT session 2 of the ROUTEsession 1 is transmitted on the transport bearer of ATSC3.0 identifiedby the transport bearer ID “atsc-bid1” (S35).

In addition, in FIG. 17, in the extended LSID, as the attribute of theLCT session 1 of the ROUTE session 2, the TSI “tsi1”, the source IPaddress “sIPAdrs1”, and the destination IP address “dIPAdrs1”, and theport number “Port1” are designated. In the attribute of the LCT session1, as the transport bearer ID for identifying the transport bearer,“atsc-bid3” and “3gpp-bid2” are designated.

The reception side system 20 can be connected to the transport bearer ofATSC3.0 identified by the transport bearer ID “atsc-bid3” according tothe information about the attribute of the LCT session 1 in the extendedLSID (S37). Similarly, the reception side system 20 can be connected tothe transport bearer of 3GPP-MBMS identified by the transport bearer ID“3gpp-bid2” according to the information about the attribute of the LCTsession 1 in the extended LSID (S38).

Then, the reception side system 20 can acquire data (IP/UDP/LCT packets)transferred through the LCT session 1 of the ROUTE session 2 identifiedby the source IP address “sIPAdrs1”, the destination IP address“dIPAdrs2”, the port number “Port1”, and TSI “tsi1” according to theinformation about the attributes of the LCT session 1 in the extendedLSID (S39). It should be noted that the LCT session 1 of the ROUTEsession 2 is transmitted on the transport bearer of ATSC3.0 or thetransport bearer of 3GPP-MBMS identified by the transport bearer ID“atsc-bid3” or “3gpp-bid2” (S37, S38).

As described above, the transport bearer ID is described into theattributes of each LCT session of the extended LSID, whereby the ROUTEsession (the LCT session) and the transport bearer are mapped, and thetransport bearer transmitted by a plurality of the transmission systemssuch as ATSC3.0 and 3GPP-MBMS can be appropriately selected.

(Example of Extended LSID Structure)

Next, referring to FIG. 18 to FIG. 21, illustrative structure anddescription of the extended LSID will be described.

(First Structure)

FIG. 18 is a diagram showing a first structure of the extended LSID inan XML format.

Note that in FIG. 18, for simplifying the description, elements andattributes of the extended LSID that are overlapped with those of theLSID in FIG. 13 and that not directly relate to the present technologyare omitted for description. Also in FIG. 18, “@” marks are attached tothe attributes but are not attached to the elements. Indented elementsand attributes are described for upper elements. These relationships aresimilar to those of other LSID structure described later.

In FIG. 18, the LSID element as a route element is an upper element of aTransportSession element. In the TransportSession element, informationabout the transport session is designated.

The TransportSession element is an upper element of a tsi attribute, aBroadcastStreamID attribute, a PLPID attribute, a TMGI attribute, aDVBTriplet-pid attribute, a sourceIPAddress attribute, adestinationIPAddress attribute, a port attribute, and a SourceFlowelement.

The TSI for identifying the LCT session is designated in the tsiattribute as an attribute value.

The broadcast stream ID specified by ATSC3.0 is designated in theBroadcastStreamID attribute as an attribute value. The PLPID isdesignated by ATSC3.0 is specified in the PLPID attribute as anattribute value. Note that the BroadcastStreamID attribute and the PLPIDattribute are optional attributes when the transport bearer of ATSC3.0is transmitted.

The TMGI specified by 3GPP-MBMS is designated in the TMGI attribute asan attribute value. Note that the TMGI attribute is an optionalattribute when the transport bearer of 3GPP-MBMS is transmitted.

A set of the DVB triplet that is a combination of the original networkID, the transport ID, and the service ID and the packet ID is designatedin the DVBTriplet-pid attribute. Note that the DVBTriplet-pid attributeis an optional attribute when the DVB-based IP broadcasting transportbearer is transmitted.

The source IP address is designated in the sourceIPAddress attribute asan attribute value. The destination IP address is designated in thedestinationIPAddress attribute as an attribute value. The port number isdesignated in the port attribute as an attribute value. Note that thesourceIPAddress attribute, the destinationIPAddress attribute, and theport attribute are optional attributes.

Information about a source flow is designated in the SourceFlow elementas an attribute value. Note that the SourceFlow element is an optionalattribute.

Here, referring to FIG. 19, a specific description example of the firststructure of an extended LSID defined in FIG. 18 will be described. FIG.19 shows the extended LSID when the transport bearers of ATSC3.0,3GPP-MBMS, and DVB-based IP broadcasting are transmitted.

In FIG. 19, the transport bearers of ATSC3.0, 3GPP-MBMS, and DVB-basedIP broadcasting are transmitted to the TransportSession element. TheBroadcastStreamID attribute, the PLPID attribute, the TMGI attribute,and the DVBTriplet-pid attribute are described among optional attributesother than the tsi attribute.

“xxx” is designated in the tsi attribute as a value of TSI.

“yyy” is designated in the BroadcastStreamID attribute as the broadcaststream ID. In addition, “zzz” is designated in the PLPID attribute as aPLPID. That is to say, a combination of the broadcast stream ID “yyy”and the PLPID “zzz” sets the transport bearer ID for identifying thetransport bearer of ATSC3.0.

“www” is designated in the TMGI attribute as TMGI. That is to say, theTMGI “www” sets the transport bearer ID for identifying the transportbearer of 3GPP-MBMS.

As the original network ID “onidX”, as the transport ID “tsidX”, as theservice ID “sidX”, and as the packet ID “pidX” are designated in theDVBTriplet-pid attribute. That is to say, a combination of the originalnetwork ID “onidX”, the transport ID “tsidX”, the service ID “sidX”, andthe packet ID “pidX” sets the transport bearer ID for identifying theDVB-based IP broadcasting transport bearer.

In the above, the first structure of the extended LSID in the XML formathas been described.

(Second Structure)

FIG. 20 is a diagram showing a second structure of an extended LSID inan XML format.

The second structure of the extended LSID shown in FIG. 20 defines atype of the element per transport media, which is independent as anXXXBearerID element by structuring the identifier per the transportmedia as compared with the first structure of the above-describedextended LSID.

In FIG. 20, the LSID element as a route element is an upper element of aTransportSession element. Here, the TransportSession element is an upperelement of a tsi attribute, a sourceIP address attribute, adestinationIPAddress attribute, a port attribute, and a SourceFlowelement and is also an upper element of an ATSCBearerID element, a3GPPBearerID element, and a DVBTSBearerID element.

The ATSCBearerID element is an upper element of the BroadcastStreamIDattribute where the broadcasting stream ID is designated and of thePLPID attribute where the PLPID is designated. Specifically, theATSCBearerID element stores a set of the broadcasting stream ID and thePLPID. Note that the ATSCBearerID element is an optional attribute whenthe transport bearer of ATSC3.0 is transmitted.

The 3GPPBearerID element is an upper element of the TMGI attribute wherethe TMGI is designated. Specifically, the 3GPPBearerID element storesthe TMGI. Note that the 3GPPBearerID element is an optional attributewhen the transport bearer of 3GPP-MBMS is transmitted.

The DVBTSBearerID element is an upper element of the DVBTriplet-pidattribute where the DVB triplet is specified and of the pid attributewhere the packet ID is specified. Specifically, the DVBTSBearerIDelement stores a set of the DVB triplet and the packet ID. Note that theDVBTSBearerID element is an optional attribute when the transport bearerof the DVB-based IP broadcasting is transmitted.

Here, referring to FIG. 21, a specific description example of the secondstructure of the extended LSID defined in FIG. 20 will be described.FIG. 21 shows the extended LSID when the transport bearers of ATSC3.0,3GPP-MBMS, and the DVB-based IP broadcasting are transmitted.

In FIG. 21, as the transport bearers of ATSC3.0, 3GPP-MBMS, andDVB-based IP broadcasting are transmitted to the TransportSessionelement, the ATSCBearerID element, the 3GPPBearerID element, and theDVBTSBearerID element are described among optional attributes.

In the ATSCBearerID element, “yyy” is designated in theBroadcastStreamID attribute as the broadcast stream ID, and “zzz” isdesignated in the PLPID attribute as a PLPID. That is to say, acombination of the broadcast stream ID “yyy” and the PLPID “zzz” setsthe transport bearer ID for identifying the transport bearer of ATSC3.0.

In the 3GPPBearerID element, “www” is designated in the TMGI attributeas TMGI. That is to say, the TMGI “www” sets the transport bearer ID foridentifying the transport bearer of 3GPP-MBMS.

In the DVBTSBearerID element, as the original network ID “onidX”, as thetransport ID “tsidX”, as the service ID “sidX”, and as the packet ID“pidX” are designated in the DVBTriplet-pid attribute. That is to say, acombination of the original network ID “onidX”, the transport ID“tsidX”, the service ID “sidX”, and the packet ID “pidX” sets thetransport bearer ID for identifying the DVB-based IP broadcastingtransport bearer.

In the above, the second structure of the extended LSID in the XMLformat has been described.

The structure of the extended LSID shown in FIG. 18 and FIG. 20 is anexample, and other structure may be employed. Although it is describedthat an XML format is employed as a description format of the extendedLSID, it may be a text format by a markup language or a binary formatother than the MXL format.

4. Specific Application Example of System

FIG. 22 is a diagram showing a specific application example of thereception side system 20 that processes the broadcasting streamtransmitted from the reception side system 10. The application examplein FIG. 22 illustrates the case that a plurality of LCT sessionsconfiguring a plurality of ROUTE sessions are transmitted from thetransport bearer of ATSC3.0.

In FIG. 22, as an on air broadcasting stream (On Air Stream), twobroadcast waves identified by the broadcasting stream ID aretransmitted. The broadcasting stream ID is assigned to a set of the areaID and the frequency ID.

On the broadcasting stream identified by the broadcasting stream ID“BSID1”, a physical pipe of the FIT as the LLS signaling information andthe PLPID “PLPID1” are transmitted. On the physical pipe, the IP headerstoring the IP address “IPAdrs1”, and the packets to which the UDPheader storing the port number “Port1” is added are transmitted.

To the payload of the packets, the LCT packets including the LCT headerstoring the TSI “tsi-0” and the LCT payload storing the SLSsignalinginformation are provided. As the LCT packets, the LCT packets includingthe LCT header storing the TSI “tsi-v1” and the LCT payload storing thedata of video 1, and the LCT packets including the LCT header storingthe TSI “tsi-a1” and the LCT payload that store the data of audio 1 areprovided.

On the other hand, on the broadcasting stream identified by thebroadcasting stream ID “BSID2”, a physical pipe of the FIT as the LLSsignaling information and the PLPID “PLPID1” are transmitted. On thephysical pipe, the IP header storing the IP address “IPAdrs2”, and thepackets to which the UDP header storing the port number “Port1” is addedare transmitted. To the payload of the packets, the LCT packetsincluding the LCT header storing the TSI “tsi-v2” and the LCT payloadstoring the data of video 2, and the LCT packets including the LCTheader storing the TSI “tsi-a2” and the LCT payload that store the dataof audio 2 are provided.

The reception side system 20 that receives the broadcasting streamperforms the following processing.

The reception side system 20 acquires the FIT transmitted by thebroadcasting stream identified by the broadcasting stream ID “BSID1”(S51). Bootstrap information for acquiring the SLS signaling informationper service is described in the FIT. The bootstrap information is a setof the IP address, the port number, the TSI, and the PLPID for acquiringthe SLS signaling information transmitted through the ROUTE session.

The reception side system 20 acquires the SLS signaling informationtransmitted through the ROUTE session based on the bootstrap information(S52, S53). The SLS signaling information acquired in this way includesmetadata such as USD (User Service Description), MPD (Media PresentationDescription), LSID (extended LSID). In the USD, a reference source suchas the MPD and the LSID is described. By acquiring the USD first, othermetadata can be acquired.

The reception side system 20 acquires the MPD based on “mpdUri”specified in a mpdUri attribute of a userServiceDescription element inthe USD (S54). In addition, the reception side system 20 acquires theLSID (extended LSID) based on “IsidUri” specified in auserServiceDescription element of an IsidUri attribute in the USD (S55).

Here, a Period element, an AdaptationSet element, and a Representationelement are described in the MPD in a hierarchical structure. The Periodelement is a unit for describing the service configuration such as thecontents. The AdaptationSet element and the Representation element areutilized per stream such as video, audio and a caption, and can describethe attributes of the respective streams.

The Representation element can designate a representation ID by an idattribute. In the MPD, to a

Representation element identified by the representation ID“RepresentationID-v1”, an attribute relating to a stream of the video 1is described, to a Representation element identified by therepresentation ID “RepresentationID-v2”, an attribute relating to astream of the video 2 is described.

In addition, in the MPD, to a Representation element identified by therepresentation ID “RepresentationID-a1”, an attribute relating to astream of the audio 1 is described, to a Representation elementidentified by the representation ID “RepresentationID-a2”, an attributerelating to a stream of the audio 2 is described. When the URL specifiedby the Representation element in the MPD is matched with the URLspecified by the DeliveryMethod element in the USD, a delivery path ofthe video or audio stream is specified as a broadcasting path or acommunication path.

In the LSID (extended LSID), the tsi attribute, the BroadcastStreamIDattribute, the PLPID attribute, the sourceIPAddress attribute, thedestinationIPAddress attribute, and the port attribute are described perTransportSession element. In the SourceFlow element, the representationID is specified as the Applicationidentifier element. Specifically, therepresentation ID shows a correspondence between the Representationelement of the MPD and the transport session of the LSID (extendedLSID).

Among the TransportSession elements enumerated in the LSID (extendedLSID), in the first TransportSession element, the broadcasting stream ID“BSID1” and the PLPID “PLPID1” are specified, whereby the reception sidesystem 20 can connect to the transport bearer of AISC3.0 identified bythe transport bearer ID (S56). Also, in the first TransportSessionelement, the source IP address “sIPArs1”, the destination IP address“IPArs1”, the port number “Port1”, and the TSI “tsi-v1” are specified.Accordingly, by filtering using these parameters, the reception sidesystem 20 can acquire the data of the video 1 (a chunked file of theDASH segment file of the video 1) transmitted through the LCT session ofthe ROUTE session (S56).

In the second TransportSession element, the broadcasting stream ID“BSID1” and the PLPID “PLPID1” are specified, whereby the reception sidesystem 20 can connect to the transport bearer of ATSC3.0 identified bythe transport bearer ID (S57). Also, in the second TransportSessionelement, the source IP address “sIPArs1”, the destination IP address“IPArs1”, the port number “Port1”, and the TSI “tsi-a1” are specified.Accordingly, by filtering using these parameters, the reception sidesystem 20 can acquire the data of the audio 1 (a chunked file of theDASH segment file of the audio 1) transmitted through the LCT session ofthe ROUTE session (S57).

In the third TransportSession element, the broadcasting stream ID“BSID2” and the PLPID “PLPID1” are specified, whereby the reception sidesystem 20 can connect to the transport bearer of ATSC3.0 identified bythe transport bearer ID (S58). Also, in the third TransportSessionelement, the source IP address “sIPArs1”, the destination IP address“IPArs2”, the port number “Port1”, and the TSI “tsi-v2” are specified.Accordingly, by filtering using these parameters, the reception sidesystem 20 can acquire the data of the video 2 (a chunked file of theDASH segment file of the video 2) transmitted through the LCT session ofthe ROUTE session (S58).

In the fourth TransportSession element, the broadcasting stream ID“BSID2” and the PLPID “PLPID1” are specified, whereby the reception sidesystem 20 can connect to the transport bearer of ATSC3.0 identified bythe transport bearer ID (S59). Also, in the fourth TransportSessionelement, the source IP address “sIPArs1”, the destination IP address“IPArs2”, the port number “Port1”, and the TSI “tsi-a2” are specified.Accordingly, by filtering using these parameters, the reception sidesystem 20 can acquire the data of the audio 2 (a chunked file of theDASH segment file of the audio 2) transmitted through the LCT session ofthe ROUTE session (S59).

In the LSID (extended LSID) in FIG. 22, in the SourceFlow element, as adeliveryObjectFormatID element of the PayloadFormat element, “2” isspecified. This shows that the format of the LCT payload is a DASHsegment file (chunked) with an HTTP entity header.

5. Apparatuses Configuration in System

(Configuration Example of Transmission Side System)

FIG. 23 is a diagram showing a configuration example of the transmissionside system 10 in FIG. 10.

The transmission side system 10 is configured of the data server 10A,the ROUTE server 10B, the ATSC broadcasting server 10C and the 3GPPMBMSserver 10D.

In FIG. 23, the data server 10A is configured of the control unit 111A,a session request unit 112A, a transmission/reception unit 113A, a datatransfer processing unit 114A, and a data holding unit 115A.

The control unit 111A controls operations of each unit of the dataserver 10A.

When data of contents (for example, contents suitable for thesimultaneous multi-destination delivery) is transmitted through theROUTE session (the LCT session), the session request unit 112A suppliesthe transmission/reception unit 113A with an establishment request ofthe ROUTE session to the ROUTE server 10B according to the control bythe control unit 111A.

The transmission/reception unit 113A exchanges a variety of data withother servers such as the ROUTE server 105 according to the control bythe control unit 111A. The transmission/reception unit 113A transmitsthe establishment request of the ROUTE session to the ROUTE server 105according to the control by the control unit 111A.

The data transfer processing unit 114A acquires the data of the contentsheld in the data holding unit 115A, and supplies it to thetransmission/reception unit 113A according to the control by the controlunit 111A. The transmission/reception unit 113A transmits the data ofthe contents to the ROUTE server 10B according to the control by thecontrol unit 111A.

The data server 10A is configured as described above.

In FIG. 23, the ROUTE server 10B is configured of the control unit 111B,a session processing unit 112B, the transmission/reception unit 113B,the LSID generator 114B and the ROUTE data generator 115B.

The control unit 111B controls operations of the respective units of theROUTE server 10B.

The session processing unit 112B performs processing for transmittingthe data of the contents through the ROUTE session according to thecontrol by the control unit 111B.

For example, when the ROUTE data that is the data of the contentstransmitted through the ROUTE session is transmitted on the transportbearer of ATSC3.0, the session processing unit 112B supplies thetransmission/reception unit 113B with a reservation request of atransport resource of ATSC3.0 to the ATSC broadcasting server 10C. Forexample, when the ROUTE data is transmitted on the transport bearer of3GPP-MBMS, the session processing unit 112B supplies thetransmission/reception unit 113B with a reservation request of atransport resource of 3GPP-MBMS to the 3GPPMBMS server 10D.

The transmission/reception unit 113B exchanges a variety of data withother servers such as the ATSC broadcasting server 10C or the 3GPPMBMSserver 10D according to the control by the control unit 111B. Thetransmission/reception unit 113B transmits the reservation request ofthe transport resource of ATSC3.0 or 3GPP-MBMS to the ATSC broadcastingserver 10C or the 3GPPMBMS server 10D according to the control by thecontrol unit 111B. The transmission/reception unit 113B receives thetransport bearer ID of ATSC3.0 or 3GPP-MBMS transmitted from the ATSCbroadcasting server 10C or the 3GPPMBMS server 10D, and supplies it tothe session processing unit 112B according to the control by the controlunit 111B.

The session processing unit 112B supplies the LSID generator 114B withthe transport bearer ID of ATSC3.0 or 3GPP-MBMS supplied from thetransmission/reception unit 113B according to the control by the controlunit 111B.

The LSID generator 114B generates the transport bearer ID of ATSC3.0 or3GPP-MBMS supplied from the session processing unit 112B, and theextended LSID based on original data of the extended LSID according tothe control by the control unit 111B. Here, for example, the extendedLSID in FIG. 19 and FIG. 21 is generated and is supplied to thetransmission/reception unit 113B. The transmission/reception unit 113Btransmits the ATSC broadcasting server 10C or the 3GPPMBMS server 100with the extended LSID supplied from the LSID generator 114B accordingto the control by the control unit 111B.

The transmission/reception unit 113B receives the data of the contentstransmitted from the data server 10A, and supplies it to the ROUTE datagenerator 115B according to the control by the control unit 111B. TheROUTE data generator 115B generates the ROUTE data based on the data ofthe contents supplied from the transmission/reception unit 113B, andsupplies it to the transmission/reception unit 113B according to thecontrol by the control unit 111B. The transmission/reception unit 113Btransmits the ROUTE data supplied from the ROUTE data generator 115B tothe ATSC broadcasting server 10C or the 3GPPMBMS server 10D according tothe control by the control unit 111B.

The ROUTE server 10B is configured as described above.

In FIG. 23, the ATSC broadcasting server 10C is configured of thecontrol unit 111C, a bearer processing unit 112C, thetransmission/reception unit 113C, a transfer processing unit 114C and atransmission unit 115C.

The control unit 111C controls operations of the respective units of theATSC broadcasting server 10C. The transmission/reception unit 113Cexchanges a variety of data with other servers such as the ROUTE server10B according to the control by the control unit 111C.

The transmission/reception unit 113C receives the reservation request ofthe transport resource of ATSC3.0 transmitted from the ROUTE server 10B,and supplies it to the bearer processing unit 112C. The bearerprocessing unit 112C ensures the transport resource of ATSC3.0 upon areservation request supplied from the transmission/reception unit 113Caccording to the control by the control unit 111C.

The bearer processing unit 112C generates the transport bearer ID ofATSC3.0 upon the reservation request supplied from thetransmission/reception unit 113C, and supplies it to thetransmission/reception unit 113C according to the control by the controlunit 111C. The transmission/reception unit 113C transmits the ROUTEserver 10B with the transport bearer ID of ATSC3.0 supplied from thebearer processing unit 112C according to the control by the control unit111C.

The transmission/reception unit 113C receives the extended LSIDtransmitted from the ROUTE server 10B, and supplies it to the transferprocessing unit 114C. The transfer processing unit 114C appliesprocessing to transfer the extended LSID and to supply it to thetransmission unit 115C according to the control by the control unit111C. The transmission unit 115C transmits (transfers) the extended LSIDsupplied from the transfer processing unit 114C to the reception sidesystem 20 (ATSC broadcasting client 20C) via the antenna 116C and thetransmission path 80.

Furthermore, the transmission/reception unit 113C receives the ROUTEdata transmitted from the ROUTE server 10B, and supplies it to thetransfer processing unit 114C. The transfer processing unit 114C appliesprocessing to transfer the ROUTE data on the transport bearer ofATSC3.0, and to supply the bearer data thus obtained to the transmissionunit 115C according to the control by the control unit 111C. Thetransmission unit 115C transmit (transfer) the bearer data supplied fromthe transfer processing unit 114C to the reception side system 20 (ATSCbroadcasting client 20C) via the antenna 116C and the transmission path80.

The ATSC broadcasting server 10C is configured as described above.

In FIG. 23, the 3GPPMBMS server 10D is configured of the control unit111D, the bearer processing unit 112D, the transmission/reception unit113D, the transfer processing unit 114D, and the transmission unit 115D.

The control unit 111D controls operations of the respective units of the3GPPMBMS server 10D. The transmission/reception unit 113D exchanges avariety of data with other servers such as the ROUTE server 10Baccording to the control by the control unit 111D.

The transmission/reception unit 113D receives the reservation request ofthe transport resource of 3GPP-MBMS transmitted from the ROUTE server10B, and supplies it to the bearer processing unit 112D. The bearerprocessing unit 112D ensures the transport resource of 3GPP-MBMS upon areservation request supplied from the transmission/reception unit 113Daccording to the control by the control unit 111D.

The bearer processing unit 112D generates the transport bearer ID of3GPP-MBMS upon the reservation request supplied from thetransmission/reception unit 113D, and supplies it to thetransmission/reception unit 113D according to the control by the controlunit 111D. The transmission/reception unit 113D transmits the ROUTEserver 10B with the transport bearer ID of 3GPP-MBMS supplied from thebearer processing unit 112D according to the control by the control unit111D.

The transmission/reception unit 113D receives the extended LSIDtransmitted from the ROUTE server 10B, and supplies it to the transferprocessing unit 114D. The transfer processing unit 114D appliesprocessing to transfer the extended LSID and to supply it to thetransmission unit 115D according to the control by the control unit111D. The transmission unit 115D transmits (transfers) the extended LSIDsupplied from the transfer processing unit 114D to the reception sidesystem 20 (3GPPMBMS client 20D) via the antenna 116D and thetransmission path 80.

Furthermore, the transmission/reception unit 113D receives the ROUTEdata transmitted from the ROUTE server 10B, and supplies it to thetransfer processing unit 114D. The transfer processing unit 114D appliesprocessing to transfer the ROUTE data on the transport bearer of3GPP-MBMS, and to supply the bearer data thus obtained to thetransmission unit 115D according to the control by the control unit111D. The transmission unit 115D transmits (transfers) the bearer datasupplied from the transfer processing unit 114D to the reception sidesystem 20 (3GPPMBMS client 20D) via the antenna 116D and thetransmission path 80.

The 3GPPMBMS server 10D is configured as described above.

(Configuration Example of Reception Side System)

FIG. 24 is a diagram showing a configuration example of the receptionside system 20 in FIG. 10.

The reception side system 20 is configured of the data client 20A, theROUTE client 20B, the ATSC broadcasting client 20C, and the 3GPPMBMSclient 20D.

In FIG. 24, 3GPPMBMS client 20D is configured of the control unit 211D,a reception unit 212D, a transfer processing unit 213D, and atransmission/reception unit 214C.

The control unit 211D controls operations of the respective units of the3GPPMBMS client 20D.

The reception unit 212D receives the extended LSID via an antenna 215transmitted from the transmission side system 10 (3GPPMBMS server 10D)via the transmission path 90, and supplies it to the transfer processingunit 213D according to the control by a control unit 211D. The transferprocessing unit 213D applies processing to transfer the extended LSIDand to supply it to the transmission/reception unit 214D according tothe control by the control unit 111D. The transmission/reception unit214D transmits the extended LSID supplied from the transfer processingunit 213D to the ROUTE client 20B according to the control by a controlunit 211D.

The reception unit 212D receives the bearer data via an antenna 215Dtransmitted from the transmission side system 10 (3GPPMBMS server 10D)via the transmission path 90 according to the control by the controlunit 211D, and supplies it to the transfer processing unit 213D. Thetransfer processing unit 213D processes the bearer data for transmittingthe ROUTE data over the transport bearer of 3GPP-MBMS, and supplies itto the transmission/reception unit 214D according to the control by thecontrol unit 211D. The transmission/reception unit 214D transmits thebearer data supplied from the transfer processing unit 213D to the ROUTEclient 200 according to the control by the control unit 211D.

The 3GPPMBMS client 20D is configured as described above.

In FIG. 24, an ATSC broadcasting client 20C is configured of a controlunit 211C, a reception unit 212C, a transfer processing unit 213C, and atransmission/reception unit 214C.

The control unit 211C controls operations of the respective units of theATSC broadcasting client 20C.

The reception unit 212C receives the extended LSID via an antenna 215Ctransmitted from the transmission side system 10 (ATSC broadcastingserver 10C) via the transmission path 80 and, and supplies it to thetransfer processing unit 213C according to the control by the controlunit 211C. The transfer processing unit 213C performs processing fortransferring to the extended LSID, and supplies it totransmission/reception unit 214C according to the control by the controlunit 211C. The transmission/reception unit 214C transmits the extendedLSID supplied from the transfer processing unit 213C to the ROUTE client20B according to the control by the control unit 211C.

The reception unit 212C receives the bearer data via the antenna 215Ctransmitted from the transmission side system 10 (ATSC broadcastingserver 10C) via the transmission path 80, and supplies it to thetransfer processing unit 213C according to the control by the controlunit 211C. The transfer processing unit 213C processes the bearer datafor transmitting the ROUTE data on the transport bearer of ATSC3.0, andsupplies it to the transmission/reception unit 214C according to thecontrol by the control unit 211C. The transmission/reception unit 214Ctransmits the bearer data supplied from the transfer processing unit213C to the ROUTE client 20B according to the control by the controlunit 211C.

The ATSC broadcasting client 20C is configured as described above.

In FIG. 24, the ROUTE client 20B is configured of a control unit 211B, atransmission/reception unit 212B, an LSID analyzer 213B, and a transferprocessing unit 214B.

The control unit 211B controls operations of the respective units of theROUTE client 20B.

The transmission/reception unit 212B receives the extended LSIDtransmitted from the 3GPPMBMS client 200 or the ATSC broadcasting client20C, and supplies it to the LSID analyzer 213B according to the controlby the control unit 211B.

The LSID analyzer 213B analyzes the extended LSID (for example, theextended LSID in FIG. 19 or FIG. 21) supplied from thetransmission/reception unit 212B, and supplies an analyzed result to thetransfer processing unit 214B according to the control by the controlunit 211B. Also, the LSID analyzer 213B selects the transport bearer foracquiring the ROUTE data according to the analyzed result of theextended LSID, and supplies a selection result to the transferprocessing unit 214B.

The transmission/reception unit 212B receives the bearer datatransmitted from the 3GPPMBMS client 20D or the ATSC broadcasting client20C, and supplies it to the transfer processing unit 214B according tothe control by the control unit 211B. The transfer processing unit 214Bselects the bearer data (transport bearer of 3GPP-MBMS or ATSC3.0)according to the selection result of the transport bearer from the LSIDanalyzer 213B. Also, the transfer processing unit 214B acquires theROUTE data transmitted by the selected bearer data (on the transportbearer of 3GPP-MBMS or ATSC3.0), and supplies it to thetransmission/reception unit 212B.

The transmission/reception unit 212B transmits the ROUTE data suppliedfrom the transfer processing unit 214B to the data client 20A accordingto the control by the control unit 211B.

The ROUTE client 20B is configured as described above.

In FIG. 24, the data client 20A is configured of a control unit 211A, atransmission/reception unit 212A, a regeneration control unit 213A, adisplay 214A, and a speaker 215A.

The control unit 211A controls operations of the respective units of thedata client 20A.

The transmission/reception unit 212A receives the ROUTE data transmittedfrom the ROUTE client 20B, and supplies it to the regeneration controlunit 213A according to the control by the control unit 211A.

The regeneration control unit 213A performs rendering on the ROUTE datasupplied from the transmission/reception unit 212A according to thecontrol by the control unit 211A. By the rendering, video data of thecontents (for example, contents suitable for the simultaneousmulti-destination delivery) is supplied to the display 214A, and audiodata is supplied to a speaker 215A.

The display 214A displays video corresponding to the video data suppliedfrom the regeneration control unit 213A according to the control by thecontrol unit 211A. Also, the speaker 215A outputs sound corresponding tothe audio data supplied from the regeneration control unit 213Aaccording to the control by the control unit 211A.

The data client 20A is configured as described above.

6. Flow of Processing Executed by Apparatuses in System

Next, a flow of processing executed by apparatuses configuring thetransmission side system 10 and the reception side system 20 in thetransmission system 1 will be described.

(Flow of Processing by Apparatuses of Transmission Side System)

First, referring to a flow chart in FIG. 25, a flow of processing byapparatuses in the transmission side system 10 will be described.

In Step S111, the session request unit 112A of the data server 10Acontrols the transmission/reception unit 113A according to the controlby the control unit 111A, and requests an establishment of the ROUTEsession to the ROUTE server 105. The establishment request for thesession from the data server 10A is received by thetransmission/reception unit 113B of the ROUTE server 10B.

In Step S131, the session processing unit 112B of the ROUTE server 10Bdetermines whether or not the establishment request of the session fromthe data server 10A requests a delivery using the transport bearer ofATSC3.0.

In Step S131, if it is determined that the delivery using the transportbearer of ATSC3.0 is requested, the processing proceeds to Step S132. InStep S132, the session processing unit 112B of the ROUTE server 10Bcontrols the transmission/reception unit 113B according to the controlby the control unit 111B, and requests a reservation of a transportresource of ATSC3.0 to the ATSC broadcasting server 100C. Thereservation request of the transport resource of ATSC3.0 from the ROUTEserver 10B is received by the transmission/reception unit 113C of theATSC broadcasting server 10C.

In Step S151, the bearer processing unit 112C of the ATSC broadcastingserver 10C ensures the transport resource of ATSC3.0 corresponding tothe reservation request of ATSC3.0 according to the control by thecontrol unit 111C.

In Step S152, the bearer processing unit 112C of the ATSC broadcastingserver 10C generates the transport bearer ID of ATSC3.0 according to thecontrol by the control unit 111C, and notifies it to the ROUTE server10B via the transmission/reception unit 113C. The transport bearer ID ofATSC3.0 from the ATSC broadcasting server 10C is received by thetransmission/reception unit 113B of the ROUTE server 10B.

Note that, in Step S131, if it is determined that the delivery using thetransport bearer of ATSC3.0 is not requested, the above-describedprocessing in Steps S132, S151 and S152 is skipped.

In Step S133, the session processing unit 112B of the ROUTE server 10Bdetermines whether or not the establishment request of the session fromthe data server 10A requests the delivery using the transport bearer of3GPP-MBMS.

In Step S133, if it is determined that the delivery using the transportbearer of 3GPP-MBMS is requested, the processing proceeds to Step S134.In Step S134, the session processing unit 112B of the ROUTE server 10Bcontrols the transmission/reception unit 113B according to the controlby the control unit 111B, and requests a reservation of a transportresource of 3GPP-MBMS to the 3GPPMBMS server 10D. The reservationrequest of the transport resource of 3GPP-MBMS from the 3GPPMBMS 10D isreceived by the transmission/reception unit 113D of the 3GPPMBMS server10D.

In Step S171, the bearer processing unit 112D of the 3GPPMBMS server 10Densures the transport resource of 3GPP-MBMS corresponding to thereservation request of 3GPP-MBMS according to the control by the controlunit 111D.

In Step S172, the bearer processing unit 112D of the 3GPPMBMS server 10Dgenerates the transport bearer ID of 3GPP-MBMS according to the controlby the control unit 111D, and notifies it to the ROUTE server 10B viathe transmission/reception unit 113D. The transport bearer ID of3GPP-MBMS from the 3GPPMBMS server 10D is received by thetransmission/reception unit 113B of the ROUTE server 10B.

Note that, in Step S133, if it is determined that the delivery using thetransport bearer of 3GPP-MBMS is not requested, the above-describedprocessing in Steps S134, S171 and S172 is skipped.

In Step S135, the LSID generator 114B of the ROUTE server 10B generatesthe transport bearer ID of ATSC3.0 or 3GPP-MBMS supplied from thesession processing unit 112B according to the control by the controlunit 11B, and the extended LSID (for example, extended LSID in FIG. 19or FIG. 21) based on the original data for generating the extended LSID.

In Step S136, the transmission/reception unit 113B of the ROUTE server10B transmits the extended LSID generated by processing in Step S135 toat least one of the ATSC broadcasting server 100 and the 3GPPMBMS server10D according to the control by the control unit 111B.

In Step S153, the transfer processing unit 114D of the ATSC broadcastingserver 100 controls the transmission unit 115D according to the controlby the control unit 111D, when the extended LSID is received from theROUTE server 10B, whereby the extended LSID received from the ROUTEserver 10B is transmitted (transferred) to the reception side system 20(ATSC broadcasting client 20C) via the transmission path 80.

In Step S173, the transfer processing unit 114D of the 3GPPMBMS server10D controls the transmission unit 115D according to the control by thecontrol unit 111D, when the extended LSID of the ROUTE server 10B isreceived, whereby the extended LSID received from the ROUTE server 10Bis transmitted (transferred) to the reception side system 20 (3GPPMBMSclient 20D) via the transmission path 90.

In Step S112, the data transfer processing unit 114A of the data server10A acquires the data of contents held in the data holding unit 115A andcontrols the transmission/reception unit 113A according to the controlby the control unit 111A, thereby transmitting the data to the ROUTEserver 10B. The data from the data server 10A is received by thetransmission/reception unit 113B of the ROUTE server 10B.

In Step S137, the ROUTE data generator 115B of the ROUTE server 10Bgenerates the ROUTE data that is transmitted through the ROUTE sessionaccording to the control by the control unit 111B based on the data fromthe transmission/reception unit 113B.

In Step S138, the transmission/reception unit 113B of the ROUTE server10B transmits the ROUTE data generated by the processing in Step S137 toat least one of the ATSC broadcasting server 10C and the 3GPPMBMS server10D according to the control by the control unit 111B.

Here, if it is determined that the delivery using the transport bearerof ATSC3.0 is performed by the processing in Step S131, and the extendedLSID including the transport bearer ID of ATSC3.0 from the ATSCbroadcasting server 10C is generated, the ROUTE data generated by theprocessing in Step S137 is transmitted to the ATSC broadcasting server10C. If it is determined that the delivery using the transport bearer of3GPP-MBMS is performed by the processing in Step S133, and the extendedLSID including the transport bearer ID of 3GPP-MBMS from the 3GPPMBMSserver 10D is generated, by the ROUTE data generated by the processingin Step S137 is transmitted to the 3GPPMBMS server 10D.

In Step S154, the transfer processing unit 114C of the ATSC broadcastingserver 10C processes the ROUTE data received from the ATSC broadcastingserver 10C to be transmitted over the transport bearer of ATSC3.0according to the control by the control unit 111C, when the ROUTE datais received from the ROUTE server 10B. Then, the transfer processingunit 114C controls the transmission unit 115C according to the controlby the control unit 111C, and transmits (transfers) the bearer data (theROUTE data transmitted over the transport bearer of ATSC3.0) to thereception side system 20 (ATSC broadcasting client 20C) via thetransmission path 80.

In Step S174, the transfer processing unit 114D of the 3GPPMBMS server10D processes the ROUTE data received from the ATSC broadcasting server10C to be transmitted over the transport bearer of 3GPP-MBMS accordingto the control by the control unit 111D, when the ROUTE data is receivedfrom the ROUTE server 10B. Then, the transfer processing unit 114Dcontrols the transmission unit 115D according to the control by thecontrol unit 111D, and transmits (transfers) the bearer data (the ROUTEdata transmitted over transport bearer of 3GPP-MBMS) to the receptionside system 20 (3GPPMBMS client 20D) via the transmission path 90.

In the above, the flow of processing by the apparatuses in thetransmission side system 10 has been described.

(Flow of Processing by Apparatuses of Reception Side System)

Next, referring to a flowchart in FIG. 26, a flow of processing by theapparatuses configuring the reception side system 20 will be described.

In Step S211, it is determined that whether or not 3GPP-MBMS isdelivered. In Step S211, if it is determined that 3GPP-MBMS isdelivered, the processing proceeds to Step S212.

In Step S212, the reception unit 212D of the 3GPPMBMS client 20Dreceives the extended LSID from the transmission side system 10(3GPPMBMS server 10D) through the transmission path 90. In Step S213,the transfer processing unit 213D controls the transmission/receptionunit 214D according to the control by the control unit 211D, andtransfers the extended LSID received by the processing in Step S212 tothe ROUTE client 20B.

Note that, in Step S211, if it is determined that 3GPP-MBMS is notdelivered, the above-described processing in Steps S212 and S213 isskipped.

In Step S231, it is determined that whether or not ATS3.0 is delivered.In Step S231, if it is determined that ATSC3.0 is delivered, theprocessing proceeds to Step S232.

In Step S232, the reception unit 212C of ATSC broadcasting client 20Creceives the extended LSID transmitted from the transmission side system10 (ATSC broadcasting server 100) via the transmission path 80. In StepS233, the transfer processing unit 213C controls thetransmission/reception unit 214C according to the control by the controlunit 211C, and transfers the extended LSID received by the processing inStep S232 to the ROUTE client 20B.

Note that, in Step S211, if it is determined that ATSC3.0 is notdelivered, the above-described processing in Steps S232 and S233 isskipped.

The extended LSID transmitted from the 3GPPMBMS client 20D or the ATSCbroadcasting client 20C is received by the transmission/reception unit212B of the ROUTE client 20B.

In Step S251, the LSID analyzer 213B analyzes the extended LSID (forexample, the extended LSID in FIG. 19 or FIG. 21) from the 3GPPMBMSclient 20D or the ATSC broadcasting client 20C. In Step S252, the LSIDanalyzer 213B selects the transport bearer for acquiring the ROUTE datatransmitted through (the LCT session) the ROUTE session according to theanalyzed result in Step S252.

In Step S214, it is determined that whether or not 3GPP-MBMS isdelivered. In Step S214, if it is determined that 3GPP-MBMS isdelivered, the processing proceeds to Step S215.

In Step S215, the reception unit 212D of the 3GPPMBMS client 20Dreceives the bearer data (the ROUTE data transmitted over the transportbearer of 3GPP-MBMS) transmitted from the 3GPPMBMS server 10D via thetransmission path 90. In Step S216, the transfer processing unit 213Dcontrols the transmission/reception unit 214D according to the controlby the control unit 211D, and transfers the bearer data received by theprocessing in Step S215 to the ROUTE client 20B.

Note that, in Step S214, if it is determined that 3GPP-MBMS is notdelivered, the above-described processing in Steps S215 and S216 isskipped.

In Step S234, it is determined that whether or not ATSC3.0 is delivered.In Step S234, if it is determined that ATSC3.0 is delivered, theprocessing proceeds to Step S235.

In Step S235, the reception unit 212C of the ATSC broadcasting client20C receives the bearer data (the ROUTE data transmitted over thetransport bearer of ATSC3.0) transmitted from the ATSC broadcastingserver 10C via the transmission path 80. In Step S236, the transferprocessing unit 213C controls the transmission/reception unit 214Caccording to the control by the control unit 211C, and transfers thebearer data received by the processing in Step S235 to the ROUTE client20B.

Note that, in Step S234, if it is determined that ATSC3.0 is notdelivered, the above-described processing in Steps S235 and S236 isskipped.

The bearer data from the 3GPPMBMS client 20D (the ROUTE data transmittedover the transport bearer of 3GPP-MBMS) or the bearer data from the ATSCbroadcasting client 20C (the ROUTE data transmitted over the transportbearer of ATSC3.0) are received by the transmission/reception unit 212Bof the ROUTE client 20B.

In Step S253, the transfer processing unit 214B of the ROUTE client 20Bacquires the ROUTE data transmitted over the 3GPP-MBMS or ATSC3.0transport bearer according to the selection result of the transportbearer in Step S252.

In Step S254, the transfer processing unit 214B controls thetransmission/reception unit 212B according to the control by the controlunit 211B, and transfers the ROUTE data acquired by the processing inStep S253 to the data client 20A.

In Step S271, the transmission/reception unit 212A of the data client20A receives the ROUTE data transmitted from the ROUTE client 20Baccording to the control by the control unit 211A.

In Step S272, the regeneration processing unit 213A performs renderingon the ROUTE data received by the processing in Step S271 according tothe control by the control unit 211A. By the rendering, video data ofthe contents is supplied to the display 214A, and audio data is suppliedto a speaker 215A. In this manner, the video of the contents isdisplayed on the display 214A, and the sound thereof is output from thespeaker 215A.

In the above, the flow of processing by the apparatuses configuring thereception side system 20 has been described.

7. Alternative Embodiment

In the above description, the ATSC system that is employed mainly inU.S. is described as a standard for a digital television broadcasting.Alternatively, an ISDB (Integrated Services Digital Broadcasting) systemthat is employed in Japan, etc. or a DVB system that is used in Europeancountries may be used. In addition, not only a terrestrial digitaltelevision broadcasting, but also a satellite digital televisionbroadcasting and a digital cable television broadcasting may beemployed.

In the above description, the elements and the attributes are describedwhen the signaling information is described in a Markup Language such asthe XML. The names of the elements and attributes are illustrative, andother names may be employed. For example, the broadcasting stream IDspecified in the LSID or the like may be referred to as an RF ChannelID, a Network ID, or an RF allocation ID (RF Alloc ID). Note that adifference in the names is a format difference, and substantial contentsof the elements and the attributes are not different. Similarly, thename of the signaling information is only illustrative, and other namesmay be employed.

8. Configuration of Computer

The above-mentioned series of processing may be executed by hardware ormay be executed by software. If the series of processing is executed bysoftware, programs configuring that software are installed into acomputer. FIG. 27 is a diagram showing a configuration example ofhardware of a computer that executes the above-mentioned series ofprocessing according to the programs.

In a computer 900, a CPU (Central Processing Unit) 901, a ROM (Read OnlyMemory) 902, and a RAM (Random Access Memory) 903 are connected to oneanother via a bus 904. An input/output interface 905 is furtherconnected to the bus 904. An input unit 906, an output unit 907, arecording unit 908, a communication unit 909, and a drive 910 areconnected to the input/output interface 905.

The input unit 906 is constituted of a keyboard, a mouse, a microphone,and the like. The output unit 907 is constituted of a display, aspeaker, and the like. The recording unit 908 is constituted of a harddisk, a nonvolatile memory, and the like. The communication unit 909 isconstituted of a network interface and the like. The drive 910 drives aremovable medium 911 such as a magnetic disk, an optical disc, amagneto-optical disk, and a semiconductor memory.

In the thus configured computer 900, the above-mentioned series ofprocessing is performed by the CPU 901 loading programs stored in theROM 902 and the recording unit 908 into the RAM 903 via the input/outputinterface 905 and the bus 904 and executing them.

The programs executed by the computer 900 (CPU 901) can be recorded andprovided on the removable medium 911 as a package medium, for example.Further, the programs can be provided via a wired or wirelesstransmission medium such as a local-area network, the Internet, anddigital satellite broadcasting.

In the computer 900, the programs can be installed into the recordingunit 908 via the input/output interface 905 by the removable medium 911being mounted on the drive 910. Further, the programs can be received bythe communication unit 909 via the wired or wireless transmission mediumand installed into the recording unit 908. Otherwise, the programs canbe installed into the ROM 902 or the recording unit 908 in advance.

In the present specification, the processing executed by the computeraccording to the programs does not necessarily need to be performed in atime sequence in the order described as the flowchart. That is, theprocessing executed by the computer according to the programs includesprocesses executed in parallel or individually (e.g., parallelprocessing or processing by objects). Further, the programs may beprocessed by a single computer (processing unit) or may be processed bya plurality of computers in a distributed manner.

Note that embodiments of the present technology are not limited to theabove-mentioned embodiments and various modifications can be madewithout departing from the gist of the present technology.

It should be noted that the present technology may take the followingconfigurations.

(1) A reception apparatus, including:

an acquisition unit that acquires control information includinginformation for acquiring data transmitted through a session in a firsttransmission system at a first layer in a protocol stack of an IP(Internet Protocol) transmission system and for identifying a bearerthat transmits the data in a second transmission system at a secondlayer lower than the first layer; and

a control unit that controls an operation of each unit that acquires thedata transmitted on the bearer on the basis of the control information.

(2) The reception apparatus according to (1), in which:

the first layer is a transport layer, and

the second layer is a physical layer.

(3) The reception apparatus according to (1) or (2), in which:

the control information includes a bearer ID for identifying the bearer.

(4) The reception apparatus according to any one of (1) to (3), inwhich:

the control information includes an IP address and a port number foridentifying the session.

(5) The reception apparatus according to any one of (1) to (4), inwhich:

the first transmission system is ROUTE (Real-time Object Delivery overUnidirectional Transport),

the session is one or a plurality of LCT (Layered Coding Transport)sessions that configure the ROUTE session, and

the control information is LSID (LCT Session Instance Description).

(6) The reception apparatus according to any one of (3) to (5), inwhich:

the second transmission system includes ATSC (Advanced TelevisionSystems Committee) 3.0 and 3GPP-MBMS (Third Generation PartnershipProject-Multimedia Broadcast Multicast Service),

the bearer ID of ATSC3.0 is a set of a first identifier that is a set ofan identifier assigned per reach area of a broadcast wave and anidentifier of a frequency band assigned to a broadcast wave of a certainchannel, and a second identifier that identifies each physical pipe, theeach physical pipe being obtained by dividing the frequency bandidentified by the first identifier into a plurality of physical pipeshaving different parameters, and

the bearer ID of ATSC3.0 is TMGI (Temporary Mobile Group Identity).

(7) A reception method used in a reception apparatus, including thesteps of:

acquiring control information including information for acquiring datatransmitted through a session in a first transmission system at a firstlayer in a protocol stack of an IP transmission system and foridentifying a bearer that transmits the data in a second transmissionsystem at a second layer lower than the first layer; and

controls an operation of each unit that acquires the data transmitted onthe bearer on the basis of the control information.

(8) A transmission apparatus, including:

a generation unit that generates control information includinginformation for acquiring data transmitted through a session in a firsttransmission system at a first layer in a protocol stack of an IPtransmission system and for identifying a bearer that transmits the datain a second transmission system at a second layer lower than the firstlayer; and

a transmission unit that transmits the data by the bearer identified byinformation included in the control information together with thecontrol information.

(9) The reception apparatus according to (8), in which:

the first layer is a transport layer, and

the second layer is a physical layer.

(10) The reception apparatus according to (8) or (9), in which:

the control information includes a bearer ID for identifying the bearer.

(11) The reception apparatus according to any one of (8) to (10), inwhich:

the control information includes an IP address and a port number foridentifying the session.

(12) The reception apparatus according to any one of (8) to (11), inwhich:

the first transmission system is ROUTE,

the session is one or a plurality of LCT sessions that configure theROUTE session, and

the control information is LSID.

(13) The reception apparatus according to any one of (10) to (12), inwhich:

the second transmission system includes ATSC3.0 and 3GPP-MBMS,

the bearer ID of ATSC3.0 is a set of a first identifier that is a set ofan identifier assigned per reach area of a broadcast wave and anidentifier of a frequency band assigned to a broadcast wave of a certainchannel, and a second identifier that identifies each physical pipe, theeach physical pipe being obtained by dividing the frequency bandidentified by the first identifier into a plurality of physical pipeshaving different parameters, and

the bearer ID of ATSC3.0 is TMGI.

(14) A transmission method used in a transmission apparatus, includingthe steps of:

generating control information including information for acquiring datatransmitted through a session in a first transmission system at a firstlayer in a protocol stack of an IP transmission system and foridentifying a bearer that transmits the data in a second transmissionsystem at a second layer lower than the first layer; and

transmitting the data by the bearer identified by information includedin the control information together with the control information.

DESCRIPTION OF REFERENCE SYMBOLS

1 transmission system, 10 transmission side system, 10A data server, 10BROUTE server, 10C ATSC broadcasting server, 10D 3GPPMBMS server, 20reception side system, 20A data client, 20B ROUTE client, 20C ATSCbroadcasting client, 20D 3GPPMBMS client, 80 transmission path, 90transmission path, 114B LSID generator, 115B ROUTE data generator, 114Ctransfer processing unit, 115C transmission unit, 114D transferprocessing unit, 115D transmission unit, 213A regeneration control unit,213B LSID analyzer, 214B transfer processing unit, 212C reception unit,213C transfer processing unit, 212D reception unit, 213D transferprocessing unit, 900 computer, 901 CPU

1-14. (canceled)
 15. A reception apparatus, comprising: circuitryconfigured to: receive control information regarding acquiring servicelevel signaling data transmitted through a Real-time Object Deliveryover Unidirectional Transport (ROUTE) data transport session using aROUTE protocol, the control information including at least a broadcaststream identifier identifying a bearer for the ROUTE data transportsession, and the control information further including informationregarding attributes of the ROUTE data transport session; and acquirethe service level signaling data transmitted through the ROUTE datatransport session on the bearer according to the information regardingthe attributes of the ROUTE data transport session.
 16. The receptionapparatus according to claim 15, wherein the service level signalingdata includes a user service description, a media presentationdescription, or a Layered Coding Transport (LCT) description.
 17. Thereception apparatus according to claim 15, wherein the informationregarding the attributes of the ROUTE data transport session includes anIP address and a port number for identifying the ROUTE data transportsession.
 18. The reception apparatus according to claim 15, wherein theROUTE data transport session includes one or a plurality of LayeredCoding Transport (LCT) sessions, and the control information includes anLCT Session Instance Description (LSID).
 19. The reception apparatusaccording to claim 15, wherein the bearer is transmitted using anAdvanced Television Systems Committee (ATSC) 3.0 protocol, the broadcaststream identifier identifying an ATSC 3.0 broadcast stream that uses theATSC 3.0 protocol, and the control information further includes aphysical pipe identifier identifying a physical pipe within the ATSC 3.0broadcast stream identified by the broadcast stream identifier.
 20. Areception method for a reception apparatus, the method comprising:receiving control information regarding acquiring service levelsignaling data transmitted through a Real-time Object Delivery overUnidirectional Transport (ROUTE) data transport session using a ROUTEprotocol, the control information including at least a broadcast streamidentifier identifying a bearer for the ROUTE data transport session,and the control information further including information regardingattributes of the ROUTE data transport session; and acquiring, bycircuitry of the reception apparatus, the service level signaling datatransmitted through the ROUTE data transport session on the beareraccording to the information regarding the attributes of the ROUTE datatransport session.
 21. The reception method according to claim 20,wherein the service level signaling data includes a user servicedescription, a media presentation description, or a Layered CodingTransport (LCT) description.
 22. The reception method according to claim20, wherein the information regarding the attributes of the ROUTE datatransport session includes an IP address and a port number foridentifying the ROUTE data transport session.
 23. The reception methodaccording to claim 20, wherein the ROUTE data transport session includesone or a plurality of Layered Coding Transport (LCT) sessions, and thecontrol information includes an LCT Session Instance Description (LSID).24. The reception method according to claim 20, wherein the bearer istransmitted using an Advanced Television Systems Committee (ATSC) 3.0protocol, the broadcast stream identifier identifying an ATSC 3.0broadcast stream that uses the ATSC 3.0 protocol, and the controlinformation further includes a physical pipe identifier identifying aphysical pipe within the ATSC 3.0 broadcast stream identified by thebroadcast stream identifier.
 25. A transmission apparatus, comprising:circuitry configured to: generate control information regardingtransmitting service level signaling data transmitted through aReal-time Object Delivery over Unidirectional Transport (ROUTE) datatransport session using a ROUTE protocol, the control informationincluding at least a broadcast stream identifier identifying a bearerfor the ROUTE data transport session, and the control informationfurther including information regarding attributes of the ROUTE datatransport session; output the control information for transmission; andoutput the service level signaling data for transmission through theROUTE data transport session on the bearer identified in the controlinformation.
 26. The transmission apparatus according to claim 25,wherein the service level signaling data includes a user servicedescription, a media presentation description, or a Layered CodingTransport (LCT) description.
 27. The transmission apparatus according toclaim 25, wherein the information regarding the attributes of the ROUTEdata transport session includes an IP address and a port number foridentifying the ROUTE data transport session.
 28. The transmissionapparatus according to claim 25, wherein the ROUTE data transportsession includes one or a plurality of Layered Coding Transport (LCT)sessions, and the control information includes an LCT Session InstanceDescription (LSID).
 29. The transmission apparatus according to claim25, wherein the bearer is transmitted using an Advanced TelevisionSystems Committee (ATSC) 3.0 protocol, the broadcast stream identifieridentifying an ATSC 3.0 broadcast stream that uses the ATSC 3.0protocol, and the control information further includes a physical pipeidentifier identifying a physical pipe within the ATSC 3.0 broadcaststream identified by the broadcast stream identifier.
 30. A transmissionmethod for a transmission apparatus, the method comprising: generating,by circuitry of the transmission apparatus, control informationregarding transmitting service level signaling data transmitted througha Real-time Object Delivery over Unidirectional Transport (ROUTE) datatransport session using a ROUTE protocol, the control informationincluding at least a broadcast stream identifier identifying a bearerfor the ROUTE data transport session, and the control informationfurther including information regarding attributes of the ROUTE datatransport session; outputting the control information for transmission;and outputting the service level signaling data for transmission throughthe ROUTE data transport session on the bearer identified in the controlinformation.
 31. The transmission method according to claim 30, whereinthe service level signaling data includes a user service description, amedia presentation description, or a Layered Coding Transport (LCT)description.
 32. The transmission method according to claim 30, whereinthe information regarding the attributes of the ROUTE data transportsession includes an IP address and a port number for identifying theROUTE data transport session.
 33. The transmission method according toclaim 30, wherein the ROUTE data transport session includes one or aplurality of Layered Coding Transport (LCT) sessions, and the controlinformation includes an LCT Session Instance Description (LSID).
 34. Thetransmission method according to claim 30, wherein the bearer istransmitted using an Advanced Television Systems Committee (ATSC) 3.0protocol, the broadcast stream identifier identifying an ATSC 3.0broadcast stream that uses the ATSC 3.0 protocol, and the controlinformation further includes a physical pipe identifier identifying aphysical pipe within the ATSC 3.0 broadcast stream identified by thebroadcast stream identifier.